The approaches described in this section are approaches that are known to the inventors and could be pursued. They are not necessarily approaches that have been pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section, or that those approaches are known to a person of ordinary skill in the art.
Issue tracking systems are systems that manage the creation and tracking of issues in a variety of contexts. Issue tracking systems are variously referred to a trouble ticket systems, support ticket systems, request management systems, and incident ticket systems.
As one example, an issue tracking system may be deployed for use by a helpdesk. A busy helpdesk may manage thousands, tens of thousands, or even more issues. Each issue may have a different priority, require different actions, be handled by different people, and/or be handled by multiple different people over its lifecycle. An issue tracking system may be used to assist in managing and tracking this process. When a problem is submitted to the helpdesk an issue is created and assigned (at times with a particular priority). As the issue is worked on by various users, the progress of the issue is recorded and tracked by the issue tracking system until, ideally, the issue is solved and closed. At any point during the life of the issue (and/or for historical review purposes) the issue tracking system can be queried to access information on a given issue, such as its status, the actions that have been taken, who the issue is currently assigned to etc.
An important feature of issue tracking systems is the ability for issues to be ranked relative to one another. This allows issues to be prioritized at a granular level. Issue ranking is a complex problem for various reasons, including: (a) the existence of multiple users, all of whom may want to add new issues, assign priorities or re-rank existing issues; (b) automated systems that may also add new issues and/or reorder existing issues; (c) changes to the issues may occur at the same or substantially the same time; (d) multiple actors may attempt to perform different rank operations on the same (or closely ranked) issues; (e) over time issues may become congested in the sense that their rank addresses indicate consecutive ordering without any space for a new issue to be ranked in between.
Some issue tracking systems are implemented in a clustered architecture, typically in order to increase capacity for concurrent users to work with the system and the issues maintained by the system. In a clustered architecture an issue tacking system is implemented across multiple nodes, each node of the cluster running its own instance of the issue tracking system. While end users see and interact with a single issue tracking system, any given operation may, in fact, be performed by any of the system nodes. A clustered architecture increases the complexity of issue ranking. For example, in order to effectively implement a ranking functionality the issue tracking system should be able to handle multiple concurrent modifications of the same issue (and closely ranked issues) by different users on different nodes of the cluster without the rank order of the issues being corrupted.